Demos
Introduction:
You know, I have been intrigued by codes and encryption for as long as I can remember. I think it all started when I was reading those "Hardy Boys" books.
I still enjoy reading books on the subject. It seems that the holy grail of encryption is "The Unbreakable Code". Of course, any code can be broken if the code breaker has the "keys" to the code. In my mind, an unbreakable code is one wherein a code breaker intercepts a coded message, and with the best tools available, finds it impossible to decode it.
Some History:
A letter substitution code (the basis of the cryptograms we see in the paper every day) may have been effective back when Alexander the Great was conquering the world, but coding has come a long way since then. In World War II, "pads" were very common. A pad is merely some text, identical copies of which are available to both the person sending the code and the person receiving it. Books were very popular to be used as pads. Using a pad, a coder would combine each letter of a message with a known part of the pad, and arrive at the coded letter. For example, if a word in the message was WAR, and the text in the pad was NOT, then the coded result would be:
Continuing, the code for WAR would be KPL.
This type of code is very difficult to break. It becomes easier if the same pad is used over and over again, and the code breaker has many messages to compare that were made with the same pad. The coded messages that were just about impossible to break were those made with a "one-time pad", whereby agents would have dozens or hundreds of different pads, to be discarded after a single use.
Now lets look at the situation today. Using computers, the most common method of encrypting a message is by using the XOR function. If you XOR the ASCII value of two characters, you get a result. If you then XOR the result with the ASCII value of the second character, the result is the ASCII value of the original first character. The problem arises when the character that the letter in the message is XORed with is a constant. The resulting code may look like gibberish, but in fact is not much better that a cryptogram. A code breaker looking at the coded message may note an over-abundance of CHR$(247)s and say "Ah, CHR$(247) probably stands for E", the most common letter in the english language. He would then proceed to decode the message much the same way as one would a newspaper cryptogram. I got to thinking then, that the answer would be to use a one-time pad.
Cypher:
I set out to write a program that would generate an unbreakable coded message. I realize that everyone is not as fascinated by this stuff as I am, and I also realize that the practical use of this for most people is just about nil. However, it was fun, a challenge, and I enjoyed it. For those of you who are still with me, if any, I will explain the workings of the program.
In order to use this program you will need:
First, the pad. In Cypher, the pad is a file. The file need not be a text file; using a computer, we are not limited to 26 characters - we can use the whole 256. So, it can be any file, as long as identical copies of it are available on both the sender's and recipient's computers, and it would be best if it were a fairly large file. For Liberty BASIC users, a likely candidate might be "Freeform303.tkn", which we all probably have, and it runs about 195K. A program such as Spybot on my computer, which runs about 2.9 Megs, would be even better. Those who are exchanging messages can pick their own.
What Cypher does is to XOR [the ASCII value of] a character from the message with a character from the pad, then XOR the next character with the next character in the pad, and so forth. The result of this is again XORed with a different character. This second XORing may appear to be overkill, but in fact is not. If a character is XORed with CHR$(32), [a space], all that happens is that the CASE of that character is reversed. For example, the result of: CHR$(ASC("a") XOR ASC(" ")) will be a capital "A". Conversely, XORing a capital "C" with a space results in a lower case "c". Therefore, in the event that the padfile were to have a long string of contiguous spaces, the message "This is a secret" would be coded as "tHIS IS A SECRET". Not too many people would have a problem decoding that. In the unlikely event that the second pad-string also had a simultaneous string of contiguous spaces, the characters in that portion of the message would merely change case twice, and the coded message would be identical to the original message.
Furthermore, a character XORed with CHR$(0), [a null], returns the same character - it is unchanged. For this reason, all of the spaces and nulls are removed from the second pad-string. The second XORing therefore eliminates this problem altogether, and the coded character is always different. Well, almost always. There is a minuscule chance that the second XOR will return the original character, but it would appear as just a random character. A coded message that consisted of nothing but 100 'E's would end up being as many as 100 different characters.
Now, the password. In case the pad file should become known or guessed, the password ensures that the pad characters start somewhere inside the pad file, and not at the beginning. The password is simply converted to a number which determines how far into the pad file the XORing will begin. Treat the password as you would any password. And yes, the case of the password IS significant.
ENcrypting:
A message to be encrypted can be INPUT directly into a text window, or it can be in the form of a disk file. Technically, the OUTPUT of a message to be encrypted also has those choices, but in practice, a message being encrypted should be output to a disk file. If the encrypted message is sent to a text window you cannot read it anyhow - it is just gibberish - and I have found that if you attempt to cut or copy and then paste the encrypted output, it becomes corrupted and cannot be DEcrypted.
BTW, the input file does not have to be a text file. If you want to, you can encrypt an ".exe" file and put it back together. Don't know why one would do this, though.
If the CONFIRM command about replacing the output file is a hassle, just delete it.
DEcrypting:
I would assume that the vast majority of the time, a message to be decrypted would be received as an e-mail attachment that was saved to disk, but I suppose it could come on a floppy. The only reliable way to decrypt a message is to INPUT it from a disk file. The OUTPUT can be sent to a text window to be read, or sent to a disk file. This can even be the same file from which it was input.
Security:
As I stated earlier, any code can be broken if the code breaker has the "keys". In this case, the keys are first and foremost the pad, and secondly the password. Both should be changed periodically. The password, for example, could be a base password such as "goombah" plus a number from 1 to 31. Therefore, a message sent on the 17th of the month would use a password of "goombah17". You get the idea. IMHO, if someone does not have the keys and the coded message was intercepted, it would be virtually impossible to break.
If someone wanted to get REALLY seriously into this, some changes would be made. The program would not be called Cypher, or Encryptor, but rather something more mundane like "Gomer", that would not reveal the purpose of the program. Also, I would change "Padfile" to something like "Filename", and "Password" to "Enter Text" or some such, but that is just for the dedicated 007 types.
I know, I know, I read too many spy novels.
The Demo:
As a demonstration, there is a small coded message accompanying this article called "CypherMessage.txt". If you are interested, run Cypher, select Input From a File, and Output To Text. The Padfile must be "Freeform303.tkn", and use "liberty" as the password. When the file dialog appears, navigate to CypherMessage.txt.
The Code:
The source code, Cypher.bas, also accompanies this article [Editors Note: The source code and a cyphered message are part of cypher.zip included in the newsletter archive available when the newsletter is downloaded].
It has only been tested with LB V4, as this is the only version I have ever had.